摘要
這篇文章主要探討了「AI 代理」領域的最新進展，以吳恩達團隊推出的 Translation Agent 開源工具為例，展現了 AI 如何革新翻譯的效率和準確性。文章首先介紹了 Translation Agent 的工作原理，它透過「反思工作流」模擬人類專業譯者的思考過程，將翻譯任務分解為三個步驟：初始翻譯、反思與改進、優化輸出。透過這種方式，Translation Agent 可以更有效地處理客製化需求，並提供更精準的翻譯結果。接著，文章深入分析了 LangGraph 翻譯助手的核心組件設計，包含狀態定義、輔助函數和核心節點，並以圖示和程式碼片段展示了 LangGraph 的工作流程。最後，文章展望了機器翻譯技術的未來發展方向，例如探索更多元的語言模型、自動生成術語表、評估翻譯質量的新指標等等。這篇文章提供了對 AI 機器翻譯技術發展的深刻見解，並展示了該技術在各行各業的應用潛力。

前言

在這個資訊爆炸的時代，機器翻譯已不再是科幻小說中的幻想，而是我們日常生活中不可或缺的工具。從瀏覽外語網頁到跨國商務溝通，智能翻譯正悄然改變我們與世界互動的方式。然而，傳統機器翻譯在處理高度客製化需求時往往力不從心，難以適應不同場景的語言變體和專業術語。

1. Translation Agent：吳恩達的革命性貢獻

2023年11月，人工智能巨擘吳恩達（Andrew Ng）團隊推出的開源智能翻譯系統 Translation Agent，標誌著翻譯技術的一個重要里程碑。這個系統不僅是一個翻譯工具，更像是一位能夠理解並持續優化翻譯成果的智能助手。

Translation Agent 的核心在於其創新的「反思工作流」（Reflection Workflow），這一設計巧妙地解決了傳統機器翻譯在客製化和精細控制方面的短板。

1.1 Translation Agent 的工作原理

Translation Agent 的核心優勢在於其獨特的「反思工作流」，這種創新機制模擬了人類專業譯ˇ者的思考過程，將翻譯任務細分為三個精細步驟。讓我們深入探討這個智能系統的運作原理。

1.1.1 初始翻譯：奠定基礎

在這個階段，Translation Agent 利用先進的大型語言模型（LLM）進行初步翻譯。

💡 亮點提示：LLM 不僅僅是簡單的字詞對應，它能夠理解上下文，捕捉語言的細微差別。

• 上下文理解：LLM 分析整個句子或段落，而不是孤立的單詞。
• 語言特性適應：系統會考慮源語言和目標語言的語法結構差異。
• 多樣化表達：LLM 能夠生成多種可能的翻譯版本，為後續優化提供基礎。

1.1.2 反思與改進：精煉過程

這是 Translation Agent 最與眾不同的階段。系統會"反思"初次翻譯的結果，就像一個經驗豐富的編輯審閱稿件。

• 自我評估：LLM 對初譯進行全面分析，檢查準確性、流暢度和風格。
• 問題識別：系統標記可能的錯誤，如不當的詞語選擇、語法錯誤或風格不一致。
• 改進建議：為每個識別到的問題提供具體的修改建議。

1.1.3 優化輸出：精雕細琢

• 智能整合：系統不是簡單地套用所有建議，而是權衡利弊，選擇最佳的改進方案。
• 一致性檢查：確保整個文檔的術語使用和風格保持一致。
• 最終潤色：對譯文進行最後的微調，確保自然流暢。

💡 最佳實踐建議：在使用 Translation Agent 時，可以提供特定領域的參考資料或風格指南，幫助系統更好地理解和適應您的需求。

1.2 這款 Translation Agent 可用在哪裡？

這個革命性的工具不僅提高了翻譯的效率和質量，還為各行各業帶來了新的可能性。讓我們深入探討 Translation Agent 在不同領域的創新應用。

1.2.1 國際商務：打破語言壁壘

在全球化的商業環境中，Translation Agent 成為跨國企業的得力助手。

• 即時會議翻譯：在線上或實體會議中提供近乎實時的翻譯，促進多語言團隊的無縫溝通。
• 商業文件本地化：快速準確地翻譯合同、提案和報告，同時保持專業術語的一致性。

💡 亮點提示：使用 Translation Agent 進行商業翻譯時，可以預先設置公司特定的術語表和品牌指南，確保翻譯結果符合企業風格。

1.2.2 媒體娛樂：跨文化內容製作

在娛樂產業中，Translation Agent 為內容創作者提供了強大支持。

• 電影字幕翻譯：快速生成準確的多語言字幕，同時保留原作的語言風格和文化內涵。
• 遊戲本地化：協助遊戲開發者將遊戲內容翻譯成多種語言，同時適應不同文化背景。

🔍 專業術語解釋：「本地化」不僅包括語言翻譯，還涉及文化適應和用戶體驗的調整。

1.2.3 旅遊行業：化解文化差異

Translation Agent 為旅遊業帶來了全新的服務可能。

• 即時旅遊翻譯：為遊客提供即時翻譯服務，包括路標、菜單和對話翻譯。
• 多語言旅遊指南：快速生成多語言旅遊資訊，豐富遊客的旅行體驗。

💡 最佳實踐建議：在旅遊應用中整合 Translation Agent，可以大大提升國際遊客的旅行體驗。

1.4 我們實際操作看看吳恩達的 Translation Agent

讓我們先按照官方 Github 實作看看摟

安裝需要 Poetry 套件管理器。如果你是第一次使用，參考官方教學，這可能有效：

pip install poetry

會用到語言模型，為此運行工作流程需要帶有 OPENAI_API_KEY 的 .env 檔案。請參閱 .env.sample 檔案作為範例。

為了使用 OpenAI API，我們需要設置 OPENAI_API_KEY 環境變數。在 Colab 中，我們可以使用 userdata 來安全地存儲和訪問 API 密鑰。

from google.colab import userdata

os.environ["OPENAI_API_KEY"] = userdata.get('OPENAI_API_KEY')

安全提示：請確保不要直接在代碼中暴露您的 API 密鑰。使用 Colab 的 userdata 功能是一種安全的做法。

最後是將專案環境安裝並且建置

git clone https://github.com/andrewyng/translation-agent.git
cd translation-agent
poetry install

整理要翻譯的文本

歡迎來到台灣，你可以使用北北基悠遊卡暢遊整個大台北，三天內的旅遊都可以任意搭乘交通工具，包含：高鐵、台鐵、捷運。祝你有美好的一天！

最後就是使用方法啦

import translation_agent as ta
source_lang, target_lang, country = "Traditional Chinese", "English", "Taiwan"
translation = ta.translate(source_lang, target_lang, source_text, country)

使用結果

1.5 深度解析吳恩達 Translation Agent 裡頭運作原理

我們先來看看專案中的一個關鍵組件：util.py。這個檔案就像是整個翻譯系統的工具箱，裡面裝滿了各種實用的輔助函數和工具。

util.py 包含了一系列支援性函數，這些函數雖然不直接參與翻譯過程，但卻是確保整個系統順暢運行的幕後英雄。從處理 API 請求，到文本分割，再到 token 計算，util.py 中的函數為主要翻譯邏輯提供了堅實的基礎支持。

1.5.1 核心函數邏輯

1. translate 函數：Translation Agent 的主控中樞
   這個函數是整個系統的大腦，負責協調各個部分的運作。它接收用戶的輸入（文本、源語言、目標語言和地區信息），然後決定採用單塊還是多塊翻譯策略。

• 如果文本較短（token 數量小於 MAX_TOKENS_PER_CHUNK），就使用 one_chunk_translate_text 進行單塊翻譯。
• 對於較長文本，則調用 multichunk_translation 進行分塊翻譯。

1.5.1.1 one_chunk_translate_text 函數：單塊翻譯的核心

這個函數處理較短的文本，採用三步驟翻譯法：

• 使用 one_chunk_initial_translation 獲得初始翻譯。
• 通過 one_chunk_reflect_on_translation 對翻譯進行反思和評估。
• 最後用 one_chunk_improve_translation 根據反思結果改進翻譯。

1.5.1.2 multichunk_translation 函數：長文本的翻譯專家

針對較長的文本，這個函數將文本分成多個小塊，然後對每個小塊進行三步驟翻譯：

• multichunk_initial_translation 對每個塊進行初始翻譯。
• multichunk_reflect_on_translation 對每個翻譯塊進行反思。
• multichunk_improve_translation 根據反思改進每個翻譯塊。

1.5.2 輔助函數

• num_tokens_in_string：計算文本的 token 數量。
• calculate_chunk_size：根據總 token 數和限制計算合適的塊大小。
• get_completion：與 OpenAI API 交互，獲取 AI 生成的內容。

1.5.3 函數相依關係圖

看圖可能方便理解些

提示：翻譯流程：整個翻譯過程遵循「翻譯-反思-改進」的模式，這模擬了專業翻譯者的工作流程。

2.換我們自行實作一次 Translation Agent 藉由 LangGraph

在這個章節中，我們將深入探討 LangGraph 翻譯助手的核心組件，揭示它們如何協同工作，共同打造一個高效、靈活的翻譯系統。從狀態管理到具體的翻譯邏輯，每個組件都在整個翻譯流程中扮演著關鍵角色。

2.1 環境準備

首先，我們需要安裝必要的套件：

pip install --upgrade --quiet langchain langchain-openai langgraph

為了使用 OpenAI 的服務，我們需要設置 API 金鑰：

import os
from google.colab import userdata

os.environ["OPENAI_API_KEY"] = userdata.get('OPENAI_API_KEY')

提示：請確保您已經在 OpenAI 官網註冊並獲取了 API 金鑰。

2.2 核心組件設計：深入解析 LangGraph 翻譯助手

在構建我們的 LangGraph 翻譯助手時，核心組件的設計至關重要。這些組件不僅決定了翻譯流程的效率，還直接影響了翻譯結果的質量。讓我們深入探討每個核心組件，了解其設計原理和實現細節。

2.2.1 狀態定義：TranslationState

翻譯過程的核心是 TranslationState 類，它使用 Pydantic 的 BaseModel 確保數據的一致性和類型安全。

class TranslationState(BaseModel):
    source_lang: str
    target_lang: str
    country: Optional[str] = None
    source_text: str
    source_chunks: List[str] = Field(default_factory=list)
    initial_translation: Optional[str] = None
    initial_translation_chunks: List[str] = Field(default_factory=list)
    reflection: Optional[str] = None
    reflection_chunks: List[str] = Field(default_factory=list)
    final_translation: Optional[str] = None
    final_translation_chunks: List[str] = Field(default_factory=list)

TranslationState 類是整個翻譯過程的核心。它使用 Pydantic 的 BaseModel 來確保數據的類型安全和一致性。讓我們詳細解析其中的關鍵屬性：

• source_lang 和 target_lang：明確定義翻譯的方向。
• country：可選字段，用於處理特定地區的語言變體。
• source_text：原始待翻譯文本。
• source_chunks：將長文本分割後的小塊列表，便於分段處理。
• initial_translation 和 initial_translation_chunks：初步翻譯結果。
• reflection 和 reflection_chunks：翻譯質量反思。
• final_translation 和 final_translation_chunks：最終優化後的翻譯。

使用列表存儲 chunks 允許我們靈活處理長文本，同時保持翻譯的連貫性。

💡 亮點提示：TranslationState 不僅存儲數據，還作為各處理節點間的信息傳遞媒介，確保整個翻譯過程的狀態一致性。

2.2.2 輔助函數：翻譯流程的底層支持

get_completion 函數

函數封裝了與 OpenAI API 的交互，提供了靈活的參數設置，使得在翻譯過程中能夠根據需要微調 AI 模型的行為。

def get_completion(prompt: str, system_message: str = "You are a helpful assistant.", model: str = "gpt-4-turbo", temperature: float = 0.3):
    response = openai.chat.completions.create(
        model=model,
        messages=[
            {"role": "system", "content": system_message},
            {"role": "user", "content": prompt}
        ],
        temperature=temperature
    )
    return response.choices[0].message.content

這個函數封裝了與 OpenAI API 的交互。它的設計考慮了以下幾點：

• 靈活性：通過參數化 system_message、model 和 temperature，我們可以根據不同的翻譯需求調整 AI 模型的行為。
• 簡潔性：將複雜的 API 調用簡化為一個易用的函數接口。
• 一致性：確保所有翻譯相關的 AI 調用使用相同的基礎設置。

2.2.3 num_tokens_in_string 和 calculate_chunk_size 函數

def num_tokens_in_string(input_str: str, encoding_name: str = "cl100k_base") -> int:
    encoding = get_encoding(encoding_name)
    return len(encoding.encode(input_str))

def calculate_chunk_size(token_count: int, token_limit: int) -> int:
    if token_count <= token_limit:
        return token_count
    num_chunks = (token_count + token_limit - 1) // token_limit
    chunk_size = token_count // num_chunks
    remaining_tokens = token_count % token_limit
    if remaining_tokens > 0:
        chunk_size += remaining_tokens // num_chunks
    return chunk_size

這兩個函數協同工作，確保我們能夠有效地處理長文本：

• num_tokens_in_string 利用 tiktoken 庫準確計算文本的標記數，這對於控制 API 請求的大小至關重要。
• calculate_chunk_size 智能地計算最佳的文本分割大小，確保每個分割後的塊都不會超過 API 的標記限制，同時盡可能減少分割次數。

🔍 專業術語解釋：「標記」(token) 在自然語言處理中指的是文本的最小單位，可能是單詞、標點符號或字符組合。API 通常限制每次請求的標記數量。

2.2.4 核心節點函數：翻譯流程的骨架

2.2.4.1. text_splitter_node

這個節點負責將長文本智能地分割成適合處理的小塊，是處理大規模文本翻譯的關鍵。

def text_splitter_node(state: TranslationState) -> TranslationState:
    num_tokens = num_tokens_in_string(state.source_text)
    if num_tokens < MAX_TOKENS_PER_CHUNK:
        state.source_chunks = [state.source_text]
    else:
        token_size = calculate_chunk_size(num_tokens, MAX_TOKENS_PER_CHUNK)
        text_splitter = RecursiveCharacterTextSplitter.from_tiktoken_encoder(
            model_name="gpt-4",
            chunk_size=token_size,
            chunk_overlap=0,
        )
        state.source_chunks = text_splitter.split_text(state.source_text)
    return state

這個節點負責文本的智能分割：

1. 首先檢查文本是否需要分割。
2. 如果需要，使用 RecursiveCharacterTextSplitter 進行分割，這確保了分割點在語義上的合理性。
3. 分割策略考慮了 token 限制，確保每個分割後的文本塊都在模型的處理能力範圍內。

2.2.4.2 single_chunk_translation_node

def single_chunk_translation_node(state: TranslationState) -> TranslationState:
    system_message = f"You are an expert linguist, specializing in translation from {state.source_lang} to {state.target_lang}."
    prompt = f"""Translate the following text from {state.source_lang} to {state.target_lang}.
    Do not provide any explanations or text apart from the translation.

    {state.source_lang}: {state.source_text}

    {state.target_lang}:"""
    state.initial_translation = get_completion(prompt, system_message)
    return state

這個節點執行實際的翻譯操作：

1. 使用專門的系統消息設置翻譯上下文。
2. 構建明確的翻譯提示，確保 AI 模型專注於翻譯任務。
3. 利用 get_completion 函數獲取翻譯結果。

2.2.4.3 reflection_node 和 translation_improvement_node

這兩個節點組成了翻譯質量保證的核心：

• reflection_node 分析初步翻譯，提供改進建議。
• translation_improvement_node 根據反思結果優化翻譯。

這種雙重檢查機制大大提高了最終翻譯的質量和準確性。

2.2.5 整趟流程下來：翻譯流程的協作鏈

1. 初始化： 當用戶提供原文時，TranslationState 類實例化，創建了整個翻譯過程的基礎狀態。
2. 文本分割： text_splitter_node 首先接手。它調用 num_tokens_in_string 和 calculate_chunk_size 函數來決定是否需要分割文本。如果需要，它會將長文本切分成多個管理良好的塊。
3. 逐塊翻譯： 對於每個文本塊，single_chunk_translation_node 開始工作。它利用 get_completion 函數與 OpenAI API 交互，生成初步翻譯。這裡，系統消息和精心設計的提示確保了翻譯的準確性。
4. 翻譯反思： 接著，reflection_node 登場。它審視初步翻譯，同樣使用 get_completion 函數來生成反思和改進建議。這一步驟為提升翻譯質量奠定了基礎。
5. 翻譯優化： 最後，translation_improvement_node 發揮作用。它整合了原文、初步翻譯和反思結果，再次通過 get_completion 函數生成最終的優化譯文。
6. 結果整合： 如果原文被分割過，最終的翻譯結果會被重新組合，確保輸出的連貫性。

2.3 翻譯結果呈現

2.3.1 案例ㄧ、英文到西班牙文，在台灣語境

source_lang = "English"
target_lang = "Spanish"
source_text = "Hello, how are you? This is a test of the translation system."
translated_text = run_translation(
    source_lang = source_lang,
    target_lang = target_lang,
    country = "Taiwan",
    source_text = source_text
  )
print(f"Translated text: {translated_text}")

2.3.2 案例ㄧ、正體中文到韓文，在台灣語境

source_lang = "Tradiaional Chinese"
target_lang = "Korea"
source_text = "如果您要參加即將活動,您必須先完成任務。"
translated_text = run_translation(
    source_lang = source_lang,
    target_lang = target_lang,
    country = "Taiwan",
    source_text = source_text
  )
print(f"Translated text: {translated_text}")

3. 額外延伸擴展方向

為進一步提升 Translation Agent 的性能，研究團隊正在探索以下方向：

1. LLM 多樣化實驗:Translation Agent 主要基於 GPT-4 Turbo 進行原型開發。但 AI 世界精彩紛呈，不同的語言模型可能在特定語言對上各有優勢。嘗試 BERT、T5 或 XLM-R 等其他模型，可能會在某些語言組合中帶來突破性發展。
2. 術語表生成:在專業翻譯中，術語一致性至關重要。利用 LLM 自動生成高質量術語表，將大大提升翻譯效率和準確性。至於如何將術語表無縫融入翻譯流程？方法ㄧ、在提示中直接包含術語表，方法二、設計特殊標記，讓模型優先考慮術語表中的翻譯。這是一個值得深入研究的問題。
3. 跨語言性能評估：在不同語言對中的表現如何？特別是對於低資源語言，我們需要更多的研究和優化。
4. 革新評估指標：傳統的 BLEU 分數在評估高水平翻譯時可能不夠精確。我們需要設計更好的評估指標，以捕捉文檔級別的翻譯質量。或許考慮使用 LLM 來評估翻譯質量，這可能會提供更接近人類判斷的結果。
5. 錯誤分析與優化：理解 Translation Agent 的局限性，特別是在專業領域（如法律、醫學）或特殊文本類型（如電影字幕）上的表現，對於改進系統至關重要。

即刻前往教學程式碼 Repo，親自動手體驗翻譯代理結合反思的魅力吧！別忘了給專案按個星星並持續關注更新，讓我們一起探索AI代理的新境界。

X. 參考資料

1.translation-agent Repo